Service Discovery

仮想マシンやコンテナを発見でき、お互いがネットワークで通信できるようにする

GPT-4.icon

一言で言えば：

動的に変わるサービスの場所（IPやポート）を自動で見つける仕組み

🔹 なぜ必要なのか？

従来のモノリシックなアプリでは、通信相手のサービスの場所（IP/ホスト名）は固定でした。しかし、次のような状況ではそれが通用しません。

サービスが\*\*Kubernetesなどで動的にスケール（増減）\*\*する

サービスがクラッシュして再起動するとIPが変わる

オートスケーリングなどでポートやホストが常に変わる

👆 こういった環境で、「どこに相手サービスがいるのか？」を毎回アプリケーションが把握するのは無理ですよね。

なので、「場所を動的に解決してくれる仕組み」＝Service Discoveryが登場します。

---

🔸 Service Discovery の2つの方式

① クライアントサイド・ディスカバリ

各クライアントが自分でサービスレジストリを見に行って、接続先を決める

レジストリ例: Consul, etcd, Zookeeper

負荷分散もクライアントがやる

🟢 メリット: 柔軟、高度なルーティング可能

🔴 デメリット: クライアントが賢くないといけない（実装コスト）

② サーバーサイド・ディスカバリ

クライアントは常にプロキシ（ロードバランサ）にリクエストする

プロキシが裏でサービスレジストリを参照して転送先を選ぶ

例：

🟢 メリット: クライアントは単純でOK

🔴 デメリット: プロキシに負荷が集中する可能性

Service Discovery に使われる主な仕組み

table:table

種類 用途

------------ -----------------------------------------------------

レジストリベース Consul, etcd, Eureka（Netflix）など

クラウド統合型 AWS Cloud Map, GCP Service Directory